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We present pState, a tool for developing “complex” embedded systems by integrating validation into 
the design process. The goal is to reduce validation time. To this end, qualitative and quantitative 
properties are specified in system models expressed as pCharts, an extended version of hierarchical 
state machines. These properties are specified in an intuitive way such that they can be written by 
engineers who are domain experts, without needing to be familiar with temporal logic. From the 
system model, executable code that preserves the verified properties is generated. The design is 
documented on the model and the documentation is passed as comments into the generated code. On 
the series of examples we illustrate how models and properties are specified using pState. 


1 Introduction 

The main traditional software validation techniques are peer review, testing, and performance measure¬ 
ment. Peer review is the process of static code examination by the author and colleagues. The goal 
is to detect and identify problems and to confirm main design decisions. Quantitative studies indicate 
that peer review is an effective technique which catches on average about 60% of defects Q. Software 
testing and performance measurement examine code by executing it on a specified fargef in a parficular 
environmenf. For each specified inpuf, a fesf is performed. Correcfness is defermined based on program 
execufion pafhs. If is offen nof possible fo fesf all execufion pafhs, especially in concurrenf sysfems, so 
in practice correcfness is defermined on a subsef of all possible execufable pafhs. This implies fhaf fhe 
correcfness is relafive fo fhe examined pafhs. The correcfness of soffware sysfems in fhe conventional 
soffware developmenf process, shown in Figure [TJ is relafive fo fhe specificafion and fo consequenfly 
execufed fesf cases. This process can discover errors buf cannof guaranfee correcfness: an error may still 
exisf in fhe producf. The ofher problem is fhaf errors are discovered late, when fhe producf is already 
builf. The sooner errors are found, fhe lower fhe cosf of repairing fhem is. 



Figure 1: Convenfional Soffware Design Process 

To overcome fhese fwo problems in fhe developmenf of embedded systems, a fechnique based on 
model checking is proposed. From a model fhaf describes fhe sysfem behaviour in a mafhemafically 
precise manner, a simplified model suifable for model checking is generafed. Model checking allows fo 
explore all possible system sfafes in a sysfemafic manner. In our approach, fhe sysfem model is described 
by pCharfs | [2T| , a version of hierarchical sfafe machines exfended wifh probabilistic transitions, timed 
transitions, stochastic timing, and costs/rewards. Using pCharfs we can specify bofh a sysfem and ifs 
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environment. Qualitative and quantitative properties are expressed directly in the model. Verification 
of qualitative properties returns true or false. Verification of quantitative property returns a numerical 
value. In Figure]^ the qualitative property ”in in T” states that whenever the system is in the state 

Q it should not be in the state T. The quantitative query ”l%power.max” returns the maximum value of 
power spent by the time a state is reached. 



Figure 2: Model Checking Software Design Process 

In embedded systems, the impact of the working environment and the reaction to external stimuli 
determine the correctness of a system. In order to verify those properties, a model of the environment 
has to be created together with a model of the system. If errors are detected by model checking, either the 
system model or the environment model need to be modified. Once fhe properfies are verified from fhe 
sysfem model execufable code fhaf preserves fhose properfies is generafed. The same formalism, pCharfs 
is used fo describe fhe sysfem model and fhe environmenf (unlike in classical discrefe even! sysfems). 
Code is generafed according fo fhe algorifhm presenfed in | [2T| , and fesfed on a number of case sfudies. 
Alfhough if is nof formally proved fo be correcf, we believe fhaf generafed code is trustworthy. 

The main sfrengfh of fhe model checking approach is fhe aufomafic verification based on sound 
mafhemafical foundations. The main weakness is relafed fo scalabilify, a.k.a. fhe sfafe-space-explosion 
problem, and fhe facl fhaf if verifies a sysfem model, nof fhe sysfem ifself. Because of fhaf we can say fhaf 
any model checking fechnique is only as good as fhe model of fhe sysfem ifself. Model checking tech¬ 
nique enjoys a rapidly increasing inferesf by indusfry Q because of ifs pofenfial fo make fhe engineering 
process more efficienf. 


2 Related Work 


Probabilisfic fransifions can be used fo express randomized algorifhms or quanfify fhe uncerfainfy of 
the environment. Probabilistic descriptions are useful for analyzing quality of service, response time, 
unreliable environments, and fault-tolerant systems. Quantitative queries can also be attached to any 
state in a state hierarchy. In general, quantitative queries are specified in the temporal logic PCTL Q 
with operators for probabilities and costs/rewards. Analysis in pState proceeds by generating from the 
visual specification a Markov Decision Process (MDP) model and quantitative queries that are passed 


to a probabilistic model checker. An MDP model of PRISM pA| corresponds to a probabilistic timed 
automaton of I 


Modelling tools like RHAPSODY, Stateflow with Simulink, Papyrus, Yakindu, SCADE Suite, and 
lAR visualSTATE do not support invariants, probabilistic transitions, stochastic transitions and direct 
cost/rewards specification. In 


translation of extended UML diagrams 1101 to PRISM is proposed, 
but parallel composed system is passed as a system of multiple models to PRISM. This process does not 
allow nested concurrency representation, only top level concurrency. On the other hand pState translates 
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arbitrarily nested parallel compositions and creates one model. Advantage is that in addition to the model 
checker input code, it is possible to generate executable code, so pState is not only a PRISM front-end. 

We use PRISM for two reasons: (1) pChart’s normal form of transitions correspond to the form of 
the input commands to PRISM, and (2) PRISM shows better overall performance compared to other 
probabilistic model checking tools like ETMCC, MRMC, YMER, VESTA | |23| . PRISM uses efficient 
algorithms and data structures based on binary decision diagrams that allow compact representation and 
increase tool scalability pA| . 

Model checking tools based on exhaustive checking are feasible only for systems with up to 10^-10^ 
states. To address this problem, statistical model checking (SMC) which solves the verification problem 
for stochastic systems in a less precise but still rigorous and efficient way is introduced Q. UPPAAE 
tool with SMC extension is capable to verify systems with more than 10^ states, so it can verify bigger 
systems than pState but in less precise manner. 

The original motivation for this work came from the design of REID tags for postal systems p^ . 
The use of PRISM for wireless network protocols is further studied in l|7|, where the example in Eigurej^ 
is specified by a simple sfafe diagram. Overall our fhrusf is fo have a fool founded in solid fheory and 
is infuifive enough fo be used by engineers for analyzing design Iradeoffs. An overview of pState wifh 


examples of generated code is in 1201. In fhis work we focus on fhe properly specificafion and generation 
of fhe documenlafionQ 


Requirements-oriented Semantics. Hierarchical sfafe machines, pCharls, are meanl primarily for fhe 
design of embedded synchronous reacfive sysfems. Transitions in fhe fop level sfafes have priorify over 
fransifions in lower level stales. Resel always bring fhe system fo ils inifial sfafe, and Ihere is no hislory 
Iransilions. We can Ihink of a pCharls as a compacf represenlalion of a flal-stale machine. On fhe 
response fo an exfemal even!, a pCharls may broadcasl addilional evenls. The execufion sfep complefes 
as soon as fhe chain of reactions comes fo a hall pY| . Wifh embedded sysfems in mind, pCharls follow 
an event-centric inlerprelafion, in which evenls are execulable procedures, implying lhal Iheir execufion 


is fasl enough and no queuing of evenls is needed |26|. Thai is, if an evenl leads fo broadcasting of 
anofher evenl, fhe second one is execuled like a called procedure, rafher fhan queued. This is in confrasf 
fo fhe state-centric inferprefalion in UME and Slafemafe Q, in which evenls are dala in queues. These 
inferprefalions are called requirements-oriented and implementation-oriented semanlics in ||^, wifh our 
evenl-cenlric inlerprelafion being fhe requiremenls-orienled semanlics. 

A number of quanfilafive exlensions of slalecharls, similar fo pCharls, have been proposed, all based 
on UME slate machines pO|[TT|T^ 281. These follow a slale-cenlric inlerprelafion where fhe slate of a 
charl is given by ils configuralion (fhe “sfafes” of fhe currenl sfafe), a sel of evenls, and fhe valuation of 


the variables (e.g. p. 67 in 1101). In pCharts, the state consists only of the configuration and the valuation 
of the variables, thus reducing the state space and facilitating model checking. UME state machines 
events have a single receiving object, whereas pCharts follow the original Stalemate interpretation and 
always broadcast events to all concurrent states. 

The event-centric interpretation allows pCharts to be represented through probabilistic guarded com¬ 
mands (H- The translation is simple and intuitive enough to serve as the definition of pCharts. The 
definition supports state hierarchies with inter-level transitions and concurrent states with broadcasting 
in arbitrary combinations. The event-centric translation of statecharts without probabilities in | p7| , gen¬ 
erates nested guarded commands as supported in the B Method l[T 26|. However, for the purpose of 
probabilistic model checking, aflat structure of guarded commands is needed. A probabilistic guarded 


^pState can be downloaded at http: //pstate. mcmaster. ca 











B. Nokovic & E. Sekerinski 


75 


command is in normal form if it is a nondeterministic choice among a set of guarded statements, 


b\ ^ Si\\ ■ ■ ■ \\bm^ Sm 


where each bi is a Boolean expression, each S, is a probabilistic choice among multiple assignment 
statements Aj with probability pf. 

Pi ■ A1 0 • • • 0 Pfii . Am 


Thus pState translates pCharts to probabilistic guarded commands in normal form. A variation is used 
to translate sub-charts without probabilistic choice to nested control structures, which can be executed 
more efficiently than flat guarded commands. From an intermediate representation of nested control 
structures C code generation is currently supported. We extend the hierarchical chart structure to allow 
the specification of a cost/reward of being in a state and of taking a transition. We are not aware that 
costs in this form have been considered for hierarchical charts. In pState the cost/reward specifications 
are first validated and then translated as annotations of the generated probabilistic guarded commands. 
A theory for costs/rewards in that form is given by priced probabilistic automata-, a recent overview with 
model checking procedures is given in 1221. 


3 Property Specification 

The example of the wireless sender and mobile receiver in Figure illustrates the basic elements of 
pCharts. The setup is typical for networks of sensors, in particular RFID tags. The state System is an 
AND (concurrent) state with children Sender and Receiver, separated by a dashed line. Both Sender and 
Receiver are XOR states with Basic states as children. The sender is initially in the state Sleep and the 
receiver in Listening. The sender exits sleep mode on a wake-up event. For active RFID tags|^ that event 
can be created either by a low frequency electromagnetic field, by a motion sensor, or by an internal 
timer. When this event is generated by a motion sensor or an internal timer, the sender always goes into 
transmission mode. On the other hand, an electromagnetic field can be created by system antennas (good 
field), or by other sources like power lines, monitors, cell phones, or electrical machines (parasite field). 
A good field has a unique identification number. If the sender recognizes the field number, it goes into 
transmission mode; otherwise it goes back into sleep mode. This is expressed by a probabilistic transition 
that with probability 0.4 goes to state Sending and with probability 0.6 goes back to state Sleeping. A 
sent message may reach the receiver or may get lost. This is expressed by another probabilistic transition 
that with probability 0.9 broadcasts msg to the receiver, which causes the receiver to go from Listening to 
Ojf. The receiver then shuts off to save power, while the sender (with unidirectional transmission) keeps 
retransmitting the message. 

We wish to analyze the following properties of the system: 

• Is the system correct in the sense that the receiver is attentive when needed? We express this by 
attaching the invariant {Sender\r\ Sleeping) ^{Receiverln Ojf) to the state System-, pState reports 
true. 

• What is the minimal probability that the receiver shuts off? We express this by attaching the query 
IP.min to state Ojf-, pState reports I.O. 

• What is the maximal number of expected message transitions of the sender until the receiver shuts 
off? For this, we attach the cost of %tran = 1 to the sending transition and ask what the maximal 

^http://www.lyngsoesystems.com/Canada/Tags.asp 
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Figure 3: Sender-receiver 


expected value of tran upon entering state Off is by attaching the query l$tran.max to Off\ pState 
reports 1.11. 

• What is the maximal expected energy consumption until the message reaches the receiver? For 
this, we attach the cost of %energy = 0.1 to state Sleep and %energy = 2 to Sending. Now we can 
ask what the maximal expected value of energy is in state Off by attaching the query ISenergy.max 
to Off-, pState reports 2.39. 


• Is the probability that the receiver shuts off at least 0.5? We express this by attaching the query 
P > 0.5 to Off-, pState reports true. 

In general, state invariants are safety conditions that can be attached to any state in a state hierarchy 
and specify what has to hold in that state. Every incoming transition to the state must ensure that the state 
invariant holds, and every outgoing transition can assume that the invariant holds. State invariants can 
express safety of an embedded system or consistency of a software system. The accumulated invariant 
of a state consists of a conjunction of invariants “inherited” from ancestor states and a combination 
of invariants of descendant states. For example, the accumulated invariant of System is the invariant 
attached to System and the invariant of Sleeping or Sending and the invariant of Listening or Off. We have 
implemented accumulated invariants in pCharts following the definition and algorithm of |27|. When 
using a model checker for invariant verification, we interpret invariants as temporal always-conditions 
rather than as inductive invariants as in | [25| . For this example pState generates the code in Figure]^ 
Queries in PRISM are specified separafely from fhe PRISM model. In fhis section, state refers fo 
stales of PRISM models, i.e. configuralions of pCharls and path is a sequence of PRISM sfafes. The 
Boolean-valued query P ~ r\pathprop\, where ~ is <,<=,>,>=, =, is Irue in a slate if fhe probabilily 
thal pathprop is satisfied by fhe palhs from lhal slate is ~ r. Among fhe pafh properfies fhal can be 
specified is fhe always properly, wriflen G prop. The invarianf {Sender in Sleeping) ^{Receiver'm Off) 
of sfafe System is Iranslaled by pState as: 


P >= l[G{{sender = Sleeping) =>\{receiver = Off))] 
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mdp 

const Sending=0; const Sleeping=l; 
const Off=0; const Listening=1; 

module SenderReceiver 

sender :[0..1] init Sleeping; 
receiver :[0..1] init Listening; 

[wup] (sender=Sleeping) —> 0.6:(sender’=Sending) + 0.4:( sender’=Sleeping); 
[send] (sender=Sending) &(receiver != Listening) —> 0.1:(sender’=Sending) + 
0.9:( sender’=Sending); 

[send] (sender=Sending) &(receiver=Listening) —> 0.1:(sender’=Sending) + 
0.9:( sender’=Sending)& (receiver ’=Off); 

endmodule 

// State rewards 
rewards ’’energy” 

(sender=Sending): 2; 

(sender=Sleeping): 0.1; 

endrewards 

// Transition rewards 
rewards ”tran” 

[send] true:l; 
endrewards 


Figure 4: Generated Code for Sender-reeeiver Code 


The real-valued queries Pmin =l\pathprop\ and Pmax =l\pathprop\ return the minimal and maximal 
probability, whieh may differ due to nondeterminism. The query for the minimal probability that the 
reeeiver eventually shuts off uses the eventually operator F prop: 

Pmin =1[F {receiver = Ojf)] 

The total reward for a path is the sum of the state rewards plus transition rewards along the path. The 
Boolean-valued query R ~ r[rewardprop\, evaluates to true in a state if the expected reward assoeiated 
with rewardprop is ~ r when starting from that state. The real-valued queries Rmin =7[rewardprop] 
and Rmax =7[rewardprop] return the minimal and maximal reward, whieh may again differ due to non¬ 
determinism. For rewardprop we eonsider only the reachability reward F prop, whieh is the reward 
aeeumulated along a path until a state satisfying prop is reaehed. The maximum expeeted number of 
transmission attempts of the sender until a message reaehes the reeeiver and the reeeiver shuts off is 
expressed as follows; as several reward structures ean be speeified, reward formulae have to refer to the 
strueture, here tran: 

R{”tran”}max =7[F {receiver = Off)] 

For the maximal energy pState generates: 

R{”energy”}max =7[F {receiver = Off)] 

The maximal expeeted energy is ealeulated by PRISM as 2.39. If the transitions were reliable, the result 
would be 2.1. Sueh analysis ean be used to evaluate tradeoffs. For example, if we assume that spending 
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10% more energy for sending increases the probability of successful ttansmission to 0.98, we obtain that 
1.02 transmission attempts are needed. This gives an appealing alternative to the practice of basing such 
evaluations exclusively on lab experiments. 


3.1 The Logic PCTL in pCharts 

pCharts allows both model design and property specification in the same hierarchical state structure, 
while the specification of properties in the PRISM model is done separately from the model itself. To 
express a query decsribing minimal probability to reach some state, we need to write formula 

Pmin =1[F (scopeVariable = state)] 


in PRISM. In pCharts, we do not need to write full formula. By writing only ”?Pmin” and attaching 
it to the state of interest we can specify the same property. The tool pState creates a PRISM formula by 
automatically taking into account the sates hierarchy. In a similar way it is possible to specify a reward 
property by ”?tran.max” which is translated into the reward formula 


R{”tran”}max =l[F{scopeVariable = state)] 


Properties are specified according to the following grammar: 


Formula {probability \ reward){” |>|<)(”mar” 

probability ::= ”P” 

reward :: = identifier 

time ::= digit{digit}(^'d”\”h”\”s”\”ms”\”ps”) 

identifier ::= letter {letter \ digit{ 


”min” I real) [”F < ” time] 


Another way to specify the property is to write the formula in the special formula text-box. The properties 
are written in PCTL |[^ 131, a probabilistic extension of temporal logic CTL Q. The logic for MDP and 
PTA properties specification is similar, the difference is that PTA property includes clock constraints. 
PTA has two model checking engines digital clocks 1151 and stochastic games (T^. In the digital clock 
engine, clock variables are allowed in P operator expressions and temporal logic property types F and 
U can be used. However, this engine does not support time-bounded reachability properties, as the one 
used in the section|^example. 


3.2 Floating Formula Example 

For the system of seven states {50,... ,56} and five transitions {tO,... ,i4} in Fig. we want to find 
out the minimal probability to reach a particular state. The initial state is 50 and probabilistic transition 
tO moves the system to 51 with 30% probability and to 52 with 70% probability. This is indicated by 
two alternatives @0.3 and @0.7 going from the P pseudo-state to the states 51 and 52. To find out the 
minimal probability of reaching state 53, we need to place the pCharts formula IP.min in the state 53. 
pState creates the PRISM formula 

Pmin =?[F{root = 53)] 

which returns 0.03 as the verification result, as can be verified manually by multiplying the probabilities 
0.3 and 0.1. 
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Figure 5: Probability of State Reachability 


To determine the probability of entering S4, which can be reached on three different paths SO —SI —?■ 
S3 —)• S4, SO —)• SI —)■ S4, and SO —?■ S2 —)• S4, it is sufficient to move the formula IP.min from state S3 to 
state S4, as shown in Figure 



Figure 6: Moving Formula From One State to Another 


Verification of 

Pmin =l[F{root = S4)] 

returns that minimal probability to reach state S4 is 0.4446. Moving formula box to state S6, pState 
creates formula 

Pmin =?[F{root = S6)] 

which as result returns 0.6499, that is actually 0.65. The error comes from floating point rounding of the 
model checker. This would be difficult to calculate manually since there are five different paths to reach 
this state. 

In this example we calculated minimal probability, but since there are no nondeterministic transitions 
in the system, the calculation of the maximal probability by ”lP.max” would return the same result. 

4 Documentation in pCharts 

The design can be documented using text boxes in the model itself. The comments are inserted in the 
generated code. There are three types of comments general comments, state comments and transition 
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comments. The main reason for including the documentation is to justify the design. Passing the com¬ 
ments to the generated code allows for forward and backward traceability, which would be necessary for 
the certification of the generated code. 

Each comment can be connected to either a state or a transition by dashed comment line. If it is 
not connected, it is associated to the state surrounding the comment box. General comments are placed 
outside any states and are technically associated to the root state. 


State Documentation As the generated code is event centric, i.e. states become variables and events 
become procedures, the comments about a state are inserted in the generated code where the state is 
declared. 


Transition Documentation A transition comment is inserted into generated code of transition event. 
The comment is connected to the transition by Comment Connector figure. Timed transitions do not have 
an associated event name, but a name is generated for the corresponding procedure and the comment is 
associated to that procedure in the same way as for untimed events. 


Example In Fig.[^ a simple transition from state Ojf to state On on the event poweron is shown. In the 
grey text-box connected by a dashed line to the state Ojf, the description of the state is given. Another 
option to describe the state is to place description text-box in the state, as it is shown for Off. Code 
generated for this example is shown in Figure 


Off 


On 


0 »■ 

The light is on 


\ poweron 


The light is off 


The event is 
generated \A/hen 
switch is on 


Figure 7: State and Transition Documentation 


5 Case Study - RFID Tag 

In the pCharts model of Fig. we analyze properties of an RFID tag used in postal systems. The model 
has two concurrent states. Tag and Environment. In the Tag state the basic operation of the RFID device 
is represented. Initially, a tag is in StandBy and on wakeUp goes into Receive. This event is broadcasted 
by Environment. The environment is initially in NoField and on event jieldOn it goes to SystemField or to 
Interference. Based on testing we estimate that approximately 30% of the time the tag will be excited by 
a system field and in 70% of time it will be excited by some unwanted field which may come from some 
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/* Variables */ 

enum root status {Off, On} root; 

// Off - The light is off 
// On — The light is on 

int main(void){ 

/* Initialization */ 
root = Off; 

return 0; 

} 

// The event is generated when the switch is on 
void poweron(void){ 

if ((root == Off)) { 
root = On; 

} 

} 


Figure 8: Generated Code for Simple Transition with Comments 


other sources of low frequency like computers, TV, some machinery, etc. On the transition to System- 
Field, the event wakeUp is generated. After time TO it goes back to NoField and increments counterB, 
which counts valid excitations. On the event Tl, environment goes from Interference to NoField state. 
We associate the interference cost interf = 1 to this transition. 

On the tag side, in Receive, we read the system field ID. If the field ID is recognized, the tag goes 
into the Transition, and if not, it goes back into StandBy. We estimate that a tag can recognize the field 
ID 80% of the time. Once it finishes the messages transition, the tag goes back into Sleep and increases 
successful transmissions counter counterA. In each state of Tag, we specify the costs of being in that 
state. This is used to evaluate power consumption and for optimization of the system. 

By selecting View —)■ Verify the MDP model of the pCharts is built and passed to the PRISM model 
checker together with properties. In a separate window the result of property verification is displayed. 
The model built by PRISM has 136955 states and 318657 transitions. In this example we verify three 
properties. Those formulas contain conditions of the counters which have to be satisfied and are not 
specified in the states, but in the formula text box. The the formula 

l$energy.min (countB = \0) (1) 

we can calculate the minimum expected energy on ten wakeUp events; the result is: 60.06. The formula 

IP.max {countA = 2)&{countB < 5) 

calculates the maximum probability of having two successful transmissions in less than five excitations. 
The result is 0.99. The formula 

2$interf .min (countB = 10) 

calculates the minimum expected number of interferences in ten good excitations. The result is: 23.33. 

If we change the probabilities of transitions, or energy consumption we can automatically calculate 
new values. For instance if the hardware design is improved by the selection of better components such 
that the energy in Receive is 1.2, formula[T]will result in 59.06; that is by decreasing state consumption for 
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Figure 9: Model of RFID Tag Excitation 


8.7% minimum expected energy on ten wakeUp events is reduced by 2.7%. If costs of new components 
and labour to alternate receiver is less than saving in energy, that alternation can be done. 

6 Case Study - Hubble Telescope 


This example is based on the model of failure of the Hubble telescope as presented in |23|. Six gyro¬ 
scopes are used for navigation. The telescope is designed such that it can fully operate with only three 
gyroscopes. When less than three gyroscopes are operational, the telescope goes into sleep mode and 
waits for repair. As long as at least one gyroscope works, the telescope is operational, otherwise it will 
crash. The goal of modelling is to find out the probability that the system will operate without failure for 
a given period of time. 

We build a formal probabilistic model of the system as a pCharts model with 13 states. In the model 
we assume that each gyroscope has an average lifetime of 10 years. Since six gyroscopes are operational, 
and any one can fail, we can expect that the outgoing rate is 6 • = 0.6, which means that there is a 

60% of chance that at least one gyroscope will fail in 365 days. That is modelled as a probabilistic 
timed transition from state SixG to state FiveG. If five gyroscopes are correcf, fhe probabilify fo have a 
failure in one year is 0.5, which is modelled as probabilisfic fransifion from slate FiveG lo slate FourG. 
When only Iwo gyroscopes are acfive, fhe lelescope needs lo go into sleep mode. The probabilily lhal Ihe 
telescope will go into sleep mode and fhe rescue operalion slarls in Ihree days is 99.8%. In lhal case, in 
approximately 60 days, wilh probabilily 0.968% all failed gyroscopes will be fixed and Ihe system goes 
into Ihe initial SixG slate. If Ihe rescue operation fails, Ihe system goes into FailOne and consecutively 
into SleepOne slate. This means only one gyroscope is functional, and Ihe telescope is in sleep mode. 
The rescue operation is laken wilhin Iwo monlhs (60 days) wilh 98.4% chance of success. While in slate 
TwoG, if Ihe system fails to go to SleepTwo slate, if will continue to work wilh Iwo gyroscopes until one 
fails in approximately 730 days. Then, il fries to go from OneG into SleepOne and to slarl Ihe rescue 
operation. The telescope can end up in Ihe Crash slate if il can nol go into sleep mode, or if Ihe rescue 
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Figure 10: pCharts Model of Hubble Space Telescope 

operation is not successful. From the model, by formula 

Pmin =?[F < 3650(root = Crash)] 

we determine that the crash probability in 10 years (3650 days) is 0.01226%, or the probability that the 
Hubble telescope will be operational in 10 years is 99.98774%. 


7 Conclusion 

This paper reports on the formalism of pCharts and its associated tool pState. The focus is on properties 
specification directly on the model in an intuitive way. We believe this technique will make the model 
checking approach more convenient for developers who are domain experts, but not software experts. 
The design can be documented and the documentation is passed to the generated code to allow trace- 
ability, e.g. for the certification of the generated code. The goal is to have a seamless and automated 
approach from modelling and analysis to code generation that can be used to evaluate design alternatives 
and generate trustworthy code. Future work will include formal proof of correctness of the generated 
code. 

Our approach is holistic, means that qualitative properties, notably structural well-formedness, cor¬ 
rectness with respect to invariants, and timing guarantees, can be verified together with quantitative 
properties, notably resource consumption, reliability, and performance. These properties cannot be ana¬ 
lyzed by considering exclusively the computerized part; rather, its environment has to be considered to 
certain extent. 
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